This section is intended to introduce the reader to various aspects of the art that may be related to of the present invention. The following discussion is intended to provide information to facilitate a better understanding of the present invention. Accordingly, it should be understood that statements in the following discussion are to be read in this light, and not as admissions of prior art.
IMS
SIP protocol is one of the core technologies used by IMS (Internet Multimedia Subsystem). It is used for control over the multimedia sessions combining voice and data streams.
IMS provides a lot of common functions used by mobile IMS networks, e.g. AAA (authentication, authorization), charging, access control, HSS (user profile databases), etc. These functions of IMS are meant to be used by the converged applications in a uniform way, so that there is no need to have separate mechanisms for these functions applied for voice communications and different ones for the data communications.
SCIM
The Service Capability Interaction Manager (SCIM) was introduced in 3GPP TS 23.002, FIG. 6a: “Functional architecture for the provision of service in the IMS” as a function within the “SIP Application Server” domain of the IMS architecture.
The role of the SCIM is that of service broker in more complex service interaction scenarios than can be supported through the service filtering mechanism; for example feature interaction management that provides intricate intelligence, such as the ability to blend Presence and other network information, or more complex and dynamic application sequencing scenarios. The SCIM as proposed to the 3GPP uses ISC and SIP interfaces to enable composite service behaviour leveraging simpler service components.
Although there is only a small amount of text in the 3GPP Release 6 specifications describing this function it is clear that it is intended to be a placeholder for an obviously necessary but vendor-defined solution to a common problem: orchestration of interaction between “Capabilities” in the larger network which are represented as SIP Application Server instances.
In practical terms, a “capability” is a system component that may be used (presumably with other components) to implement a “service” that is packaged and delivered to end users of the network. For example, a group list server and a presence server may both be considered “capabilities” that are used to implement a sophisticated conferencing service.
Service Composition
Composite services are created through aggregation of existing services. They address complex user requirements that cannot be covered by existing services. Composite services offer added value (i.e., in the form of new functionality) compared to the sum of the functionality of their building blocks.
Consider basic services and enablers like a weather forecasting service and a positioning data service. Both can be used individually, however combining them into a composite service that provides a location based weather forecast creates a new type of functionality with clear added value. For this reason composite services are often referred to as value added services.
FIG. 1 illustrates a case were a location based service, specifically a location based weather forecast is created out of two existing components, an enabler that provides location information and a weather forecast service.
The exposure of these functions as SOA services allows an application to individually discover them by querying a service repository and then individually bind them as depicted in the left part of the previous figure. The process of discovering appropriate services as well as the far more complex logic for binding them and making use of their functionality is implemented in the application itself. This functionality is symbolized by the set of gears in the application box on the left part of the figure. The developer of the application logic in this case needs to consider and cover all eventualities at design time (i.e. faulty services), possibly a number of different technologies/formats, and a host of other issues that are not directly related to the actual end-user service, but rather to the usage of the enabling services.
In contrast, service composition functionality as illustrated in the right part of the previous figure, introduces an entity—the service composition engine—that takes care of this complexity for the application. In this scenario the application implements just its core logic, whereas the enabling functionality “location-based weather forecast” is exposed by the composition engine as a single service that may be easily discovered and bound by the application. In this case the composition engine executes application logic in the form of the definition of the composite service “location-based weather forecast”. This composite service describes the type of required services, so that the engine—at run-time—may discover, bind and execute appropriate services.
Composition functionality consequently allows for great flexibility e.g. in handling events such as a faulty enabler. In this case the engine could find an alternative service without any disruption of the end-user application. This scenario is illustrated by FIG. 1.
The discussed application scenario illustrates how service composition enables the decoupling of application logic and enabling functions. By extracting parts of the logic from the application and implementing it in a formalized way with the help of a composition entity (engine) a number of advantages become possible. The application logic becomes easily reusable and adaptable, it also becomes easier to implement, since it may make use of the event-driven facilities of the composition engine.
Decoupling of application logic and exposure of functionality as reusable services is clearly facilitated by component-based software development and modelling of the application functionality. On the one hand software components (or groups thereof) already represent cleanly broken down units of functionality i.e. good candidates for services. Consequently, understanding of the application functionality based on its modelling is the basic requirement for defining aggregate application functionality in a composition.
Problems with Existing Solutions
A Service Capability Interaction Manager (or SCIM) orchestrates service delivery among application server platforms within the IP Multimedia Subsystem architecture. The Service Capability Interaction Manager (SCIM) was introduced in 3GPP TS 23.002.
In practical terms, a “capability” is a system component that may be used (presumably with other components) to implement a “service” that is packaged and delivered to end users of the network. For example, a group list server and a presence server may both be considered “capabilities” that are used to implement a sophisticated conferencing service.
Service composition technology may be used to implement a SCIM as described in references PCT/EP2007/002956 and EP 07010735-4. However, the approach described in references PCT/EP2007/002956 and EP 07010735-4 implies an increase of resources used by the Composition Engine and latency added to session establishment that corresponds to the number of constituent components included in the composite service created.
Customer requirements in this area state that the latency imposed by the SCIM node should not exceed 20 ms. In cases where the number of constituent services is small, this overall limit is possible to fulfill. However, with increased complexity of the composite-services created, the additional latency introduced by the SCIM becomes a major concern.
This invention optimizes the composition creation process by reducing the number of decisions that need to be made in order to create a new composite service. It has the potential to make composition creation latency constant regardless of the size of the composite service.